I'm not sure about this change, actually. Is there a good reason to not put the key into the secrets file? (For context, we're having the same discussion over on the encrypted config spec.)

I want to make sure we have clear erroring when keys are rotated - and also that we leave the door open to the same container potentially having 2 or more available keys at one time. Can we instead do both - put the key ID in the file so it is explicit rather than implicit - and throw an error (or at least a warning) if the key that is mentioned in the file is not the same Key ID as the one passed in the env var?

My initial thoughts around this was to simplify the encryption process (not requiring a key id). But with expectations of key rotation or multiple kms keys as an option in the future, probably worth keeping in that case. I'll refactor based on this.

My initial thoughts around this was to simplify the encryption process (not requiring a key id).

Oh, got it! Yeah, that makes sense. 👍

We can still get the KMS Key ID from env var while encrypting and then also automatically store it in the yaml, I think that's a nice balance. Edit: Per the below: we want encryption to work only with the public key, without the user needing to receive or track their KMS Key.

We can still get the KMS Key ID from env var and then also automatically store it in the yaml, I think that's a nice balance.

@aaronsteers If we want to store it in the yaml, we need it to be provided during the encrypt command. In that case, I don't see why we'd want to force it to be provided via env var.

Providing it via env var is useful for the decrypt command because it's convenient for us to inject env vars into the runner.

But don't we plan to move away from this approach towards secrets relatively soon anyway? I don't think we'll ever get around to supporting key rotation with kms-ext since by the time we can prioritize that, we'll hopefully already be using a secrets backend powered by meltano login and meltano config --secret.

We can still get the KMS Key ID from env var and then also automatically store it in the yaml, I think that's a nice balance.

@aaronsteers If we want to store it in the yaml, we need it to be provided during the encrypt command.

Yes! Thank you. I was switching context from the other issue, where there is a known explicit key at encrypt time and any number of potential decrypt keys at decrypt time. This is also true here except we're starting from the public key and not from a Key ID. Okay, I'm caught up now. Presumably the closest 'ID' we have at encrypt time is a public key fingerprint, yes? Because we don't want the user to have to concern themselves with the Key ID and also the public key while encrypting - which makes sense.

I will reread with the improved context and reply again shortly. Thanks, both.

Logged for follow-up:

• Add public key fingerprint to the encryption envelope in secrets.yml. #5

It's probably not a ton of work to add a fingerprint (MD5 or SHA-based hash of the key text), but it isn't strictly needed as of now.

But don't we plan to move away from this approach towards secrets relatively soon anyway?

That's an important question, and it does play into my thinking here. I don't expect this will fully go away with meltano/meltano#6999.

Rather than slow down this PR, I've put some thoughts into a new discussion here in this repo:

• Long-term uses #6